COMMENT ⊗   VALID 00008 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	This mailing list includes:
C00003 00003	JLK@MIT-MC 10/06/77 09:21:25
C00007 00004	MOON@MIT-MC 10/06/77 17:19:50 Re: graphics
C00011 00005	JLK@MIT-MC 10/06/77 18:37:23
C00017 00006	CFFK@MIT-MC 10/06/77 20:32:52 Re: Graphics protocol: +y should be up, not down
C00018 00007	RMS@MIT-AI 10/07/77 00:10:13
C00024 00008	BEE@MIT-MC 10/07/77 08:25:20
C00027 ENDMK
C⊗;
This mailing list includes:
JLK at MIT-MC, MOON at MIT-MC, MRC at MIT-MC, BEE at MIT-MC
CFFK at MIT-MC, MACRAK at MIT-MC, RMS at MIT-AI
(FILE [MC:JLK;.TDGRF MAIL]) at MIT-MC
JLK@MIT-MC 10/06/77 09:21:25
I heard about your SUPDUP protocol, and  it got me thinking that it  would
really be a win if  such a thing existed for  graphics as well.  Now I  am
aware of that  network graphics  protocol study  which didn't  seem to  go
anywhere.  One of the problems is that unlike SUPDUP there is almost  zero
experience with using graphics over the net.  Another one is that whenever
anyone starts thinking about  this, all kinds  of complicated issues  like
display subroutining  and the  like  get raised,  when  in fact  the  vast
majority of  hosts  and  users  only have  simple  line  drawing  graphics
hardware and software.  The jist of all  this is that it would be nice  if
the SUPDUP protocol were extended  for simple line drawing primitives  (we
have been using 200+ards  codes for this on  our software tty terminals  -
i.e. 234,235,236,237 are used for setpoint, long vector, short vector, and
exit graphics mode).  Moon  has pointed out that  ARDS codes are not  very
optimal, but no  one has yet  suggested a line  drawing protocol which  is
much  of  an  improvement.   The  most  universal  line  drawing  protocol
(Tektronix) is even more losing.  An additional command pair which we feel
would be very useful for  cleaning things up is  a general enter and  exit
graphics mode that would allow you to distinguish characters displayed  as
part of a  graph from those  treated as  part of the  display screen  (for
cursorpositioning).  We even  implement this protocol  for character  only
displays (printing or otherwise) in our PDP-11 (now it is not a great  win
but you can get a reasonable approximation).

Now a point  could be  made that  one wants  to keep  the SUPDUP  protocol
simple and unkludged by such extensions.  On the other hand there is a lot
of useful linedrawing type software available that could be used over  the
net  (and  very  little  software  that  uses  more  complicated  graphics
constructs like the DRAW program), so it would be nice if there was a  way
to sidestep the delay necessary in arriving at a general graphics protocol
(based on zero experience).  Another  alternative is to experiment with  a
line  drawing  protocol  on  ITS/SAIL  to  gain  some  experience   before
suggesting a standard.

(I just thought I'd throw these ideas in the pot to boil...)
MOON@MIT-MC 10/06/77 17:19:50 Re: graphics
It's not really MRC's protocol, he  was just the only one together  enough
to sit down and document it.   Also, it's not really a separate  protocol,
since  it's  closely  tied  to  ITS.   Yes,  I  would  like  to  see  some
line-drawing protocol.  Now that I've seen Tektronix I have to agree  it's
more losing.  Maybe  we should  just bite the  bullet and  use ARDS  code.
Except, maybe it  would be  better to flush  the strange  shifting, and  I
doubt that most people use or support dotted lines.

How about the  following?  If there's  anything wrong with  this tell  me.
Then we  can  go ahead  and  define the  characters  in the  system's  %TD
codespace; we don't have to implement anything right away.

This assumes that the codes 000 and 177 are not difficult to send.
Coordinate system:
	<dx>, <dy>  deltas.  100 bit is sign (0=down/right, 1=up/left)
				77 bits are the magnitude.
	<x>, <y> 14-bit absolute coordinates.  The actual screen
			size is device-dependent.  The high 7 bits
			are sent first.

Character codes:
	%TDGRF <x> <y> - enter graphics mode and set position to (x,y)
			if already in graphics mode, just set position.
	%TDGRX - exit graphics mode.  Must be followed by a %TDMV0,
			or could take <row>,<col> args like %TDMV0.
			The terminal is not assumed to be able to 
			remember the cursor position of one mode 
			when in the other mode.

	%TDLIN <x> <y> - draw a line from current position to (x,y)
			and move the cursor to (x,y).

	%TDVEC <dx> <dy> - similar but relative short vector, is
			this necessary?

	%TDIVC <dx> <dy> - invisible vector.  If %TDVEC exists this
			should also.

	%TDORS (output reset) should take the terminal out of graphics mode.

Conceivably these might be implemented on the AI TVs, although it wouldn't
be high-priority.  I'm not sure, but I think the SAIL TVs are not  capable
of reasonable line-drawing.
JLK@MIT-MC 10/06/77 18:37:23
(Is it likely this discussion is going to persist long enough to require a
mailing list?)

(1) Should ITS  support the  interpretation of this  protocol for  various
terminal types?  (I know  RMS is not  in favor of this,  but I'm not  sure
what the issues are.  In fact the only dumb terminal that cannot interpret
this protocol is a  tektronix.  Imlacs, TV's  etc. could easily  interpret
it. What about frobs like the new HP graphics terminal? As I mentioned, we
actually  support  the  ards  convention  for  non-graphics  terminals  by
converting to character plots.  Is this enough of a win to pursue?)

(2) What  are the  advantages of  this sign/magnitude  format rather  than
simply 2's complement?  Vector displays like plotters and IMLACS like this
form, but TV's would rather  have 2's complement.  Somehow 2's  complement
seems esthetically nicer.

(3) Relative  vectors  of some  sort  are definitely  necessary  for  some
applications, but  I  suspect  your  TDLIN primitive  would  be  the  most
commonly used  one.  It  seems to  me that  in most  cases where  relative
vectors are used, they  are used locally  (in a small  region) so I  agree
with only having  small relative vectors  (after all it  only takes a  few
ADD's to turn relative vectors into absolute ones).

(4) ARDS format  uses the command  character as a  way of entering  things
like Long Vector MODE (i.e. every 4 chars are taken as a long vector, with
no requirement that the command character be repeated).  I suppose this is
more efficient over slow communication  links, but is also less  reliable.
Do you propose to prefix each vector by the appropriate %TD code?  I think
I would prefer this.

(5) MACRAK points out  there should be an  agreed upon convention for  how
rounding of the 14-bits, down to whatever the terminal can support, should
be done (so circles come out as circles! - this exists informally for  our
TV's although I forget what the rule is).

(6) I generally like the %TDGRF and %TDGRX.  Terminals often would like to
distinguish characters output  in graphics mode  vs ordinary display  mode
(to put them in different display lists, etc.).  If you exit graphics mode
with %TDORS, where  is the  cursor supposed to  be?  If  ITS supports  the
convention for some  terminal then it  would have to  know how to  convert
between character  and vector  coordinates  for that  terminal,  requiring
information such as character size in graphic units, etc (a pain..)

(7) It would be pretty  easy to implement this  on our PDP-11 and  SIMLAC,
and to change the MACSYMA graphics package  to use it.  If a consensus  is
reached on this, I would like to do this so we could gain some  experience
with the protocol (or should we  just assume we know what we're  doing...)
It would be  win if  AI TV's  and SUPDUP  knew about  it too  so the  user
community could be expanded.  Should we solicit some input from DM?

What graphics programs are widely used on ITS's (other than programs  that
run in terminals themselves)?   I know of  MACSYMA, MUDDLE, DRAW,  GEOMED,
(programs for printing ards pictures - ARDPRN, IMPRNT or whatever).  On AI
TV's there is  LOGO and  some stuff  on TVLISP,  and various  individual's
hacks.  Others?   (I am  just curious  to  see the  range of  things  this
protocol might apply to).

Then there is the issue  of how to store these  guys on disk (8-bit  bytes
packed?) - we currently use ards or arrays of floating pt numbers.
CFFK@MIT-MC 10/06/77 20:32:52 Re: Graphics protocol: +y should be up, not down
The coordinate system  for graphics  should have  the positive  directions
being UP and right.  This is what Tektronix and Ards graphics assume,  and
conforms more closely to peoples assumptions of how a piece of graph paper
should look.
RMS@MIT-AI 10/07/77 00:10:13
1) I never  was opposed to  a system-wide graphics  protocol.  In fact,  I
have wanted one for some time.

2) I do not think that individual graphics functions should have their own
%TD codes.  Doing it that way is unnecessary, since I do not believe  that
ITS itself will ever play  any part in supporting  them, and will make  it
more difficult, slow and frightening  to define new graphics codes.   (But
it won't be impossible to make ITS support them, for some rigid  terminal,
if we must).

3) That  is important  because I  think that  we should  have a  lot  more
operations than were proposed.  There should be operations to draw  shaded
or  unshaded  circles,  squares,   triangles,  etc,  operations  to   draw
characters  or  specified  radius  dots  at  graphics  cursor   positions,
operations that  name  or refer  back  to  objects so  that  display  list
terminals can win, and ways to set the ALU function so TVs can win.  There
should be ERASE commands that give an object number and are also  followed
by commands to redraw the object, so that both display list terminals  and
raster terminals can succeed in erasing  the object.  And there should  be
any other commands that it proves useful to put in the user end instead of
the server.

4) All  that  is  needed  in  ITS  is  a  central  way  to  remember  what
capabilities the terminal has.  A new system variable is already being put
in, to hold such information.

5) So I advocate creating a  special "graphics" mode which can be  entered
and exited by some sort of user command (a ∧P code?).  The entry and  exit
will be represented in the buffer by %TDGRP and %TDGRX codes.  The  actual
graphics protocol need not be known in any way to ITS; it will consist  of
a way of interpreting characters sent while in graphics mode.  This  makes
that protocol easy to change.

6) Robustness:  The reason for having ITS know about graphics mode at  all
is that we can then make it perform a few services, such as not allow  any
other job to type out (ie,  a job outputting in graphics mode  essentially
locks  the  terminal,  even  though  other  jobs  may  also  have   output
permission).  If the job LOSES output permission (eg, because it has  been
∧Z'd) then other programs are again allowed to type out on it, and if  one
does then  a %TDGRX  must be  sent first.   .RESET should  turn off  ITS's
graphics mode bit.  The  %TDORS should inform the  terminal that it is  no
longer in graphics mode.  ITS will  start up with no terminal in  graphics
mode, so %TDINI  should inform  the terminal that  it is  not in  graphics
mode.  This implies that the graphics protocol must not make use of %TDGRX
or %TDORS or %TDINI EVER, even as  an argument.  I think it might be  best
to restrict  the graphics  protocol to  codes less  than 128.   Note  that
rubout will still  be turned into  Rubout ∧A for  hardware software  TTYs,
which most graphics terminals will presumably be.

7) Other similar services:   Many other applications will  be able to  use
this locking/resetting property.  For example, sending who-lines to IMLACs
can lose if DDT types out  in the middle.  Sending debugging commands  and
programs to be loaded are two more examples.  I think that such operations
should be defined  as subsets  of the graphics  protocol.  An  alternative
might be a new %TD code for each such class of operations, to enter a mode
that as far as  ITS knows is  just like graphics mode,  but might be  used
differently by user programs and terminals.

8) Another advantage of this scheme is  that it does not require that  the
terminal be open  in super-image output  mode.  It can  be used just  fine
with an ordinary output channel.
BEE@MIT-MC 10/07/77 08:25:20
1) No comment.

2) I agree for basically the same reason

3) This I think  is a good  idea, however with  this stipulation. I  think
that RMS has gone a  little overboard, and would  be somewhat upset if  we
spent all the time deciding what the shading commands should look like.  I
think that a better way to approach this whole problem is to just design a
simple protocol. This  protocol should  only support line  drawing at  the
start.  It however should have a lot  of "opcode" space that is not  used.
These should be made available  for user specification.  Basically when  a
command becomes  used  by several  programs,  it should  get  assigned  an
opcode.  I think that it would be self defeating to try and decide now all
the commands that are needed. Having some graphics experience  previously,
I think that it is not  important to make the hairy commands  particularly
efficient transmissionwise. The  important thing is  to make the  commonly
used ones take the  least time.  Things that  fall into that category  are
line drawing and output of characters in graphics mode.  A good model  for
this kind of scheme are the system calls and uuos of ITS.  When a  service
is supplied to many programs, the  code is centralized and a convetion  is
set. If it is just a command that one user or program wants to  implement,
it is free to  use one of the  free slots. As for  circles and shading,  I
dont think that this is particularly useful to put in the protocol.

4-6) Like I said  before, having ITS not  know a whole lot  is a win,  but
some features are important.

7-8) This is also a win, if it isn't too hard.